4-1. (참고) 프록시와 리버스 프록시

참고 1. 프록시와 리버스 프록시

개요

프록시와 리버스 프록시는 네트워크 통신에서 중계 역할을 하는 서버로, 컨테이너 환경에서 보안, 성능, 관리를 위해 필수적으로 사용됨.

프록시 vs 리버스 프록시:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[프록시 (Forward Proxy)]
클라이언트를 대신하여 요청

[클라이언트] → [프록시] → [여러 서버들]
     ↑______________|
     클라이언트 보호

[리버스 프록시 (Reverse Proxy)]
서버를 대신하여 응답

[클라이언트들] → [리버스 프록시] → [백엔드 서버들]
                       ↑_______________|
                       서버 보호

참고 1.1. 프록시 (Forward Proxy)

기본 개념

프록시는 클라이언트의 요청을 대신 전달하는 중계 서버임. 클라이언트가 직접 외부 서버에 접속하지 않고 프록시를 통해 간접적으로 접속함.

프록시 동작 방식:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[사용자 PC]
    ↓ "네이버 접속해줘"
[프록시 서버: proxy.company.com]
    ↓ 대신 접속
[네이버 서버]
    ↓ 응답
[프록시 서버]
    ↓ 전달
[사용자 PC]

특징:
→ 클라이언트가 프록시 설정
→ 외부 서버는 프록시 IP만 확인
→ 클라이언트 IP 숨김

프록시 설정 방법

클라이언트가 직접 설정:

Windows 프록시 설정:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

설정 → 네트워크 및 인터넷 → 프록시
→ 수동 프록시 설정
→ 주소: proxy.company.com
→ 포트: 8080

Chrome/Edge 프록시 설정:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

설정 → 고급 → 시스템 → 프록시 설정

HTTP Proxy: proxy.company.com:8080
HTTPS Proxy: proxy.company.com:8080

환경 변수로 설정:

# PowerShell
$env:HTTP_PROXY = "http://proxy.company.com:8080"
$env:HTTPS_PROXY = "http://proxy.company.com:8080"

# 이후 모든 HTTP 요청은 프록시 경유
Invoke-WebRequest -Uri "https://naver.com"

# Linux/Mac
export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080

# 이후 모든 HTTP 요청은 프록시 경유
curl https://naver.com

프록시 사용 목적

프록시 활용 시나리오:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[1. 보안 및 필터링]
회사 환경:
→ 유해 사이트 차단
→ 업무 시간 SNS 차단
→ 악성코드 다운로드 차단

[2. 익명성 보호]
VPN/Tor:
→ 실제 IP 주소 숨김
→ 지역 제한 우회
→ 프라이버시 보호

[3. 캐싱]
프록시 서버가 응답 저장:
→ 반복 요청 시 빠른 응답
→ 대역폭 절약
→ 서버 부하 감소

[4. 접근 제어]
네트워크 정책:
→ 특정 사이트만 허용
→ 시간대별 접근 제어
→ 사용자별 권한 관리

[5. 로깅 및 모니터링]
통신 기록:
→ 어떤 사이트 접속했는지 기록
→ 대역폭 사용량 측정
→ 보안 감사

참고 1.2. 리버스 프록시 (Reverse Proxy)

기본 개념

리버스 프록시는 서버를 대신하여 클라이언트의 요청을 받아 백엔드 서버로 전달하는 중계 서버임. 클라이언트는 리버스 프록시만 알고 실제 백엔드 서버는 알 수 없음.

리버스 프록시 동작 방식:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[사용자]
    ↓ https://example.com 접속
[NGINX 리버스 프록시]
    ↓ 요청 분석 및 전달
[백엔드 서버 1] 또는 [백엔드 서버 2] 또는 [백엔드 서버 3]
    ↓ 처리
[NGINX 리버스 프록시]
    ↓ 응답 전달
[사용자]

특징:
→ 서버 관리자가 설정
→ 클라이언트는 설정 불필요
→ 백엔드 서버 IP 숨김

도커 환경에서 리버스 프록시 구성

도커 컴포즈 예시:

version: '3.8'

services:
  # 리버스 프록시 (외부 공개)
  nginx:
    image: nginx:latest
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./certs:/etc/nginx/certs:ro
    depends_on:
      - backend
      - frontend
    networks:
      - webnet

  # 프론트엔드 (외부 미공개)
  frontend:
    image: react-app:latest
    expose:
      - "3000"
    networks:
      - webnet

  # 백엔드 (외부 미공개)
  backend:
    image: node-api:latest
    expose:
      - "8080"
    networks:
      - webnet

  # 데이터베이스 (외부 미공개)
  db:
    image: postgres:15
    expose:
      - "5432"
    networks:
      - webnet

networks:
  webnet:
    driver: bridge

NGINX 설정 예시:

http {
    # 백엔드 서버 그룹 정의
    upstream backend {
        server backend:8080;
    }

    # 프론트엔드 서버 그룹 정의
    upstream frontend {
        server frontend:3000;
    }

    # HTTP → HTTPS 리다이렉트
    server {
        listen 80;
        server_name example.com;
        return 301 https://$server_name$request_uri;
    }

    # HTTPS 서버
    server {
        listen 443 ssl;
        server_name example.com;

        ssl_certificate /etc/nginx/certs/fullchain.pem;
        ssl_certificate_key /etc/nginx/certs/privkey.pem;

        # 프론트엔드로 전달
        location / {
            proxy_pass http://frontend;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }

        # API 요청은 백엔드로 전달
        location /api/ {
            proxy_pass http://backend;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

도커 네트워크와 서비스명 기반 통신

컨테이너 이름으로 통신:

도커 네트워크 DNS:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[webnet 브리지 네트워크]
    │
    ├─ nginx 컨테이너
    │  └─ IP: 172.18.0.2
    │  └─ 호스트명: nginx
    │
    ├─ backend 컨테이너
    │  └─ IP: 172.18.0.3
    │  └─ 호스트명: backend
    │
    └─ frontend 컨테이너
       └─ IP: 172.18.0.4
       └─ 호스트명: frontend

도커 DNS 해석:
→ "backend" 입력 → 172.18.0.3으로 자동 변환
→ "frontend" 입력 → 172.18.0.4으로 자동 변환

NGINX 설정:
proxy_pass http://backend:8080;
           └─ 서비스명:포트

장점:
→ IP 주소 몰라도 됨
→ 컨테이너 재시작 시에도 이름 불변
→ 설정 관리 간편

expose vs ports 차이:

expose vs ports:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

# expose: 도커 네트워크 내부에서만 접근 가능
backend:
  expose:
    - "8080"
  # 외부(호스트)에서 접근 불가
  # nginx 컨테이너는 backend:8080으로 접근 가능

# ports: 호스트 포트에 바인딩 (외부 공개)
nginx:
  ports:
    - "443:443"
  # 외부에서 호스트:443으로 접근 가능

보안 권장사항:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[안전한 구성]
services:
  nginx:
    ports:
      - "443:443"  # 리버스 프록시만 외부 공개

  backend:
    expose:
      - "8080"  # 외부 접근 불가, nginx만 접근

→ 백엔드는 nginx를 통해서만 접근
→ 직접 접근 차단

[위험한 구성]
services:
  backend:
    ports:
      - "8080:8080"  # 외부에서 직접 접근 가능

→ nginx 우회 가능
→ 보안 취약

리버스 프록시 사용 목적

리버스 프록시 활용:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[1. 보안]
백엔드 서버 보호:
→ 실제 서버 IP 숨김
→ DDoS 공격 방어
→ WAF (Web Application Firewall) 적용
→ SSL/TLS 종료점

[2. 로드 밸런싱]
여러 서버에 부하 분산:
→ Round Robin
→ Least Connections
→ IP Hash
→ 고가용성 확보

예시:
upstream backend {
    server backend1:8080;
    server backend2:8080;
    server backend3:8080;
}

[3. 캐싱]
응답 캐싱:
→ 정적 파일 캐싱
→ API 응답 캐싱
→ 서버 부하 감소
→ 응답 속도 향상

[4. 압축]
응답 압축:
→ gzip 압축
→ 대역폭 절약
→ 전송 속도 향상

[5. SSL/TLS 관리]
인증서 중앙 관리:
→ NGINX에서만 인증서 관리
→ 백엔드는 HTTP로 통신
→ 인증서 갱신 간편

참고 1.3. 백엔드를 위한 Egress Proxy

개념

백엔드 서버가 외부 API를 호출할 때 프록시를 경유하는 패턴. 나가는 트래픽(Outbound)을 제어하고 모니터링하기 위해 사용함.

Egress Proxy 구조:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[인터넷] ← [Egress Proxy] ← [백엔드 서버]
  ↑            ↑                ↑
외부 API    중계/제어        프록시 설정

도커 환경 구성

version: '3.8'

services:
  # 백엔드 애플리케이션
  backend:
    image: myapp:latest
    environment:
      # 환경 변수로 프록시 설정
      HTTP_PROXY: http://proxy:3128
      HTTPS_PROXY: http://proxy:3128
      NO_PROXY: localhost,127.0.0.1,db,redis
    depends_on:
      - proxy
      - db
    networks:
      - internal

  # Egress Proxy
  proxy:
    image: squid:latest
    expose:
      - "3128"
    volumes:
      - ./squid.conf:/etc/squid/squid.conf:ro
    networks:
      - internal
      - external

  # 데이터베이스
  db:
    image: postgres:15
    networks:
      - internal

networks:
  internal:
    internal: true  # 외부 접속 차단
  external:
    # 인터넷 접속 가능

백엔드 코드에서 프록시 사용

환경 변수 기반 자동 프록시 사용:

// Node.js - 코드 변경 불필요
// 환경 변수만 설정하면 자동으로 프록시 사용

const axios = require('axios');

// HTTP_PROXY, HTTPS_PROXY 환경 변수를 자동으로 읽음
const response = await axios.get('https://api.example.com/data');

// 실제 동작:
// 1. axios가 HTTPS_PROXY 환경 변수 확인
// 2. proxy:3128로 연결
// 3. 프록시가 api.example.com 접속
// 4. 응답을 백엔드로 전달

# Python - 코드 변경 불필요
import requests

# HTTP_PROXY, HTTPS_PROXY 환경 변수를 자동으로 읽음
response = requests.get('https://api.example.com/data')

# 실제 동작: 환경 변수 설정된 프록시 자동 사용

HTTP vs HTTPS 프록시 통신 차이

HTTP 요청 (평문):

HTTP 프록시 요청:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[백엔드 → 프록시]
GET http://api.example.com/data HTTP/1.1
Host: api.example.com

[프록시 → 서버]
GET /data HTTP/1.1
Host: api.example.com

특징:
→ 프록시가 요청 내용 확인 가능
→ 프록시가 캐싱 가능
→ 프록시가 응답 수정 가능

HTTPS 요청 (암호화):

HTTPS 프록시 요청 (CONNECT 터널링):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[백엔드 → 프록시]
CONNECT api.example.com:443 HTTP/1.1
Host: proxy:3128

[프록시 응답]
HTTP/1.1 200 Connection Established

[백엔드 ←→ 서버] SSL/TLS 암호화 터널
GET /data HTTP/1.1
Host: api.example.com

특징:
→ 프록시는 목적지(도메인)만 알 수 있음
→ 프록시는 암호화된 내용 못 봄
→ End-to-End 암호화 유지

Squid 프록시 설정

# squid.conf
# ACL (Access Control List) 정의
acl allowed_apis dstdomain .payment.com
acl allowed_apis dstdomain .api.example.com
acl allowed_apis dstdomain .googleapis.com

# 내부 네트워크 정의
acl internal_network src 172.18.0.0/16

# 접근 규칙
http_access allow internal_network allowed_apis
http_access deny all

# 로깅
access_log /var/log/squid/access.log squid

# 캐싱
cache_dir ufs /var/spool/squid 100 16 256
maximum_object_size 4 MB

# 프록시 포트
http_port 3128

NO_PROXY 환경 변수

NO_PROXY 설정:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

NO_PROXY: localhost,127.0.0.1,db,redis

의미:
→ 해당 주소는 프록시 우회
→ 직접 연결

이유:
1. 성능: 내부 서비스까지 프록시 경유는 비효율
2. 보안: 내부 통신은 이미 안전
3. 단순성: 로깅/필터링 불필요

동작 예시:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

fetch('https://api.example.com')
→ HTTPS_PROXY 사용 → proxy:3128 → 외부 API

fetch('http://db:5432')
→ NO_PROXY 매칭 → 프록시 우회 → 직접 연결

Egress Proxy 사용 목적

Egress Proxy 활용:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[1. 보안]
화이트리스트 기반 제어:
→ 허용된 도메인만 접속 가능
→ 해킹 시 임의 서버 접속 차단
→ 데이터 유출 방지

예시:
acl allowed_domains dstdomain .api.example.com
http_access allow allowed_domains
http_access deny all  # 나머지 차단

[2. 감사 및 로깅]
모든 외부 통신 기록:
→ 어느 백엔드가
→ 언제
→ 어디에
→ 무엇을 요청했는지 추적

[3. 성능]
API 응답 캐싱:
→ 자주 호출되는 API 캐싱
→ 외부 API 호출 감소
→ 응답 속도 향상
→ 비용 절감

[4. IP 관리]
단일 IP로 외부 접속:
→ 여러 백엔드 서버
→ 프록시 하나로 통합
→ 외부 API가 IP 화이트리스트 요구 시
  프록시 IP 1개만 등록

[5. 레이트 리미팅]
API 호출 속도 제어:
→ 과도한 호출 방지
→ 외부 API 쿼터 관리
→ 비용 관리

참고 1.4. 전체 아키텍처

프로덕션 환경 구성

방법 1: 모두 컨테이너로 구성 (권장)

version: '3.8'

services:
  # Inbound: 리버스 프록시
  nginx:
    image: nginx:latest
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    networks:
      - frontend-net
      - backend-net

  # 웹 애플리케이션
  webapp:
    image: webapp:latest
    expose:
      - "3000"
    networks:
      - frontend-net
      - backend-net

  # API 서버
  api:
    image: api:latest
    environment:
      HTTP_PROXY: http://egress-proxy:3128
      HTTPS_PROXY: http://egress-proxy:3128
      NO_PROXY: localhost,db,redis
    expose:
      - "8080"
    networks:
      - backend-net
      - egress-net

  # Outbound: Egress 프록시
  egress-proxy:
    image: squid:latest
    expose:
      - "3128"
    volumes:
      - ./squid.conf:/etc/squid/squid.conf:ro
    networks:
      - egress-net
      - internet

  # 데이터베이스
  db:
    image: postgres:15
    expose:
      - "5432"
    networks:
      - backend-net

networks:
  frontend-net:
    internal: false
  backend-net:
    internal: true
  egress-net:
    internal: true
  internet:
    # 외부 접속 가능

전체 통신 흐름:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[인터넷]
    ↓ HTTPS
[NGINX (Reverse Proxy)] ← Inbound
    ↓
[Web App / API]
    ↓ 외부 API 호출 필요
[Egress Proxy (Forward Proxy)] ← Outbound
    ↓
[외부 API: payment.com, etc.]

특징:
→ 들어오는 트래픽: NGINX 제어
→ 나가는 트래픽: Egress Proxy 제어
→ 내부 통신: 도커 네트워크
→ 외부 공개: NGINX만

방법 2: 호스트 NGINX + 컨테이너

호스트 기반 구성:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[인터넷]
    ↓
[호스트 NGINX] :80, :443
    ↓ 127.0.0.1:8080
[API 컨테이너] (localhost만 바인딩)
    ↓ 127.0.0.1:5432
[DB 컨테이너] (localhost만 바인딩)

특징:
→ 호스트 NGINX가 리버스 프록시
→ 컨테이너는 localhost에만 바인딩
→ 호스트 방화벽으로 추가 보호

AWS 환경 예시

AWS VPC 구성:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[인터넷]
    ↓
[Internet Gateway]
    ↓
[Application Load Balancer] (리버스 프록시 역할)
    ↓
[Public Subnet]
    └─ NAT Gateway (Egress Proxy 역할)
        ↑
[Private Subnet]
    ├─ ECS/EC2 (백엔드 컨테이너)
    ├─ ECS/EC2 (백엔드 컨테이너)
    └─ RDS (데이터베이스)

동작:
1. 인터넷 → ALB → 백엔드 (Inbound)
2. 백엔드 → NAT → 인터넷 (Outbound)

보안:
→ Private Subnet은 외부에서 직접 접근 불가
→ ALB를 통해서만 접근 가능
→ NAT을 통해서만 외부 접속 가능

핵심 요약

프록시 vs 리버스 프록시:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[프록시 (Forward Proxy)]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

역할: 클라이언트를 대신하여 요청
설정: 클라이언트가 설정
방향: 클라이언트 → 프록시 → 외부 서버

사용 목적:
→ 클라이언트 보호/익명화
→ 콘텐츠 필터링
→ 캐싱
→ 접근 제어

예시:
→ 회사 프록시 서버
→ VPN
→ Egress Proxy (백엔드용)


[리버스 프록시 (Reverse Proxy)]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

역할: 서버를 대신하여 응답
설정: 서버 관리자가 설정
방향: 클라이언트 → 리버스 프록시 → 백엔드

사용 목적:
→ 서버 보호
→ 로드 밸런싱
→ SSL 종료
→ 캐싱
→ 압축

예시:
→ NGINX
→ Apache
→ AWS ALB/CloudFront


[Egress Proxy (백엔드용 Forward Proxy)]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

역할: 백엔드의 외부 요청 제어
설정: 환경 변수 (HTTP_PROXY, HTTPS_PROXY)
방향: 백엔드 → Egress Proxy → 외부 API

사용 목적:
→ 외부 API 호출 제어
→ 화이트리스트 관리
→ 감사 로깅
→ IP 통합 관리

예시:
→ Squid Proxy
→ AWS NAT Gateway


도커 환경 구성:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[Inbound (들어오는 트래픽)]
클라이언트 → NGINX(Reverse Proxy) → 백엔드

설정:
services:
  nginx:
    ports:
      - "443:443"  # 외부 공개
  backend:
    expose:
      - "8080"  # 내부만

NGINX 설정:
proxy_pass http://backend:8080;
           └─ 서비스명:포트


[Outbound (나가는 트래픽)]
백엔드 → Squid(Forward Proxy) → 외부 API

설정:
services:
  backend:
    environment:
      HTTP_PROXY: http://proxy:3128
      HTTPS_PROXY: http://proxy:3128
      NO_PROXY: localhost,db

코드:
// 변경 없음!
fetch('https://api.example.com')
// 자동으로 프록시 경유


핵심 원칙:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. 외부 공개: 리버스 프록시만
2. 백엔드: expose로 내부 통신
3. 외부 API: Egress Proxy 경유
4. 도커 네트워크: 서비스명으로 통신
5. 환경 변수: 프록시 자동 사용

참고 자료

공식 문서:

• NGINX Reverse Proxy: https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/
• Squid Proxy: http://www.squid-cache.org/Doc/
• Docker Networking: https://docs.docker.com/network/

관련 주제:

• AWS ALB: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/
• AWS NAT Gateway: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html